fix(devcontainer): honour the documented install switches, stream setup output, and bound every install - #62

…e connection on it

`postCreateCommand` was the object form, with two named entries: a CRLF strip
and the setup script. That shape reads as "do this, then that". It is not what
it does.

An object-form lifecycle command runs its entries in PARALLEL, and buffers each
entry's output until that entry exits. So the pair did neither of the two things
it looked like it did. The strip raced post-create.sh instead of preceding it --
both started in the same millisecond, and whether the scripts were stripped
before they were sourced was a coin toss no one had noticed winning. And the
setup entry printed nothing for the several minutes a cold tool install takes.

Minutes of total silence from a container that is provisioning normally is
indistinguishable from a deadlock. It sent someone looking for one that was not
there, which is what makes this a defect rather than a preference: the output
was being withheld precisely when it was the only evidence available.

One string joined with `&&` fixes both halves. The ordering is now real, and a
string command streams line by line as it runs.

`waitFor` moves to `onCreateCommand` for the other half of the same complaint.
post-create still runs to completion and still reports failure; it no longer
holds the VS Code connection while it does. The trade-off is stated in the file
rather than left for someone to discover: a terminal opened in the first couple
of minutes will not have `task`, `lefthook` or `claude` on PATH yet. `remoteEnv`
already points PATH at the mise shim directory, so they appear in the next
shell -- no reload, no reconnect.

Refs #59

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Ali S <amirali.sadrzadeh@gmail.com>

`.env.example` offered MUSHER_INSTALL_CLAUDE and MUSHER_INSTALL_CODEX as the
way to "skip the AI CLI installs on a slow connection", and devcontainer.json
declared both in containerEnv. Nothing read either one:

    $ git grep -n MUSHER_INSTALL -- .devcontainer/
    .env.example:29:# MUSHER_INSTALL_CLAUDE=0
    .env.example:30:# MUSHER_INSTALL_CODEX=0
    devcontainer.json:64:    "MUSHER_INSTALL_CLAUDE": "1",
    devcontainer.json:65:    "MUSHER_INSTALL_CODEX": "1"

Four lines describing a behaviour, and no fifth line implementing it. Both CLIs
installed unconditionally, and they are most of the several minutes a cold
container spends in postCreateCommand -- so the one switch a developer on a slow
connection would reach for was the one that did nothing. MUSHER_LOG_LEVEL was
the same defect in miniature: documented in the same block, read by nothing.

`install_wanted()` reads the switch and `debug()` implements the log level.
Claude Code defaults ON as this repository's harness; Codex defaults OFF,
because it is an npm package carrying a platform binary and no one should pay
for a tool they do not use on every rebuild. Codex leaves the resolved set via
MISE_DISABLE_TOOLS rather than by editing mise.toml, so the pin stays recorded
and enabling it stays a one-line change to a known version.

The pins come out of containerEnv, and this is the half that would otherwise
have made the fix cosmetic. containerEnv becomes `docker run -e`, and an
explicit -e outranks --env-file for the same name whichever order they appear
in. Pinned to "1" there, they would have overridden the .devcontainer/.env that
.env.example tells developers to edit -- two places claiming to decide this, and
the documented one losing. Defaulting in the scripts leaves .env as the single
place that decides, and a comment says so where the pins used to be.

Verification follows the same rule: it now checks the tools this container was
asked to install, because reporting a missing `codex` to the developer who
switched it off is reporting a failure they asked for.

Refs #59

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Ali S <amirali.sadrzadeh@gmail.com>

…r a missing tool

Two ways a cold build ended badly, neither of them the fault of the thing that
went wrong.

Every network install ran unbounded -- `curl | sh` for mise, `mise install`,
`curl | bash` for Claude Code. A stalled connection parks postCreateCommand for
as long as the kernel keeps the socket open, which is effectively forever, and
the developer has no output to tell them apart from a container that is simply
slow. `bounded()` wraps `timeout --foreground`, and the curls grow
`--connect-timeout 10 --max-time 120`. A stall now fails, retries, and
eventually reports -- "hangs forever" becomes "failed, and you can still work".
The ceilings sit above the whole pipeline, not the fetch of the script:
install.sh downloads a platform binary of its own after it is fetched.

Separately, `base_verify_tools` ran last under `set -e`, so one missing CLI
ended post-create.sh right there -- skipping install_lefthook_hooks and
install_spec_tools, which is the git hooks and `bun install`. A container that
was missing one tool ended up missing its hooks and its dependencies too, and
the developer learned about the second failure later than the first. That is a
worse outcome than the tool being missing warranted.

Verification now reports through its return code. The repo-specific steps run,
the status is carried to post-create.sh's exit code, and a final line names the
condition rather than leaving the developer to scroll for a ✗. The container is
still reported as half-provisioned, because it is -- it is just half-provisioned
with working git hooks.

Refs #59

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Ali S <amirali.sadrzadeh@gmail.com>